 Okay, then folks. It's nine o'clock
 In fact it says on this clock that it's five past nine, but never mind. We'll start anyway
 I am terribly sorry that it's nine o'clock in the morning and next time it will be 11 o'clock in the morning because I don't
 Know about you, but I've got a hangover
 All right, let's start this again
 So this is all about implementing animation systems what works and what doesn't
 And I got a few little animations going on here and because I work on the sims. We have sims up here doing this stuff
 So who should be here who should be listening to this who should be interested in what I've got to say
 Well people who've implemented animation system
 We're going to
 People who've I used them and experienced them and are going to be building a new one. It's pretty much what I'm aiming at
 Some background in 3d math will be helpful because I am going to talk a little bit about some stuff, but it's not really required
 So who am I and what do I know about it? Well, I work for Maxis right now
 I work on the next generation sims products. I can't tell you what it is because it hasn't been announced yet, but
 It's not going to come as a great shock to anybody when you do find out what it is. That's for certain
 So, I'm Jake Simpson
 I do have a website where you can catch up on what I do
 Jake world org I work for a Maxis as I said on next generation sims products
 I also wrote ghoul 2 for Raven when I worked there for three and a half years on the soldier fortune 2 and Jedi knight 2
 Both products used exactly the same animation system and what's not commonly known is they actually use exactly the same models
 It's actually quite possible to import models from Jedi knight into soldier fortune
 It's kind of interesting seeing stormtroopers running around inside of soldier fortune
 Anyway, I work quite a lot with the existing animation system that Maxis is using for its next generational product
 Some of it was constructed before I got there
 But I'm you know pretty heavily involved with it now and I like to talk and drink beer a lot
 I'm not sure why that's in there. So what am I not going to talk about? We're not going to cover
 Lighting and shadowing systems because they're not classically really part of the animation system
 that's more about rendering and about your rendering pipeline and
 It's not really relevant. Although
 Some shadowing systems do require transform vertex data from an animation system
 What that means effectively is you should really only render your model or your your vertices once
 So that then you can pass that information off to the rendering system so that it can then use that information to generate
 stencil shadows
 Of course that does kind of presuppose you're not using hardware acceleration, but
 Inverse and forward kinematics. I'm not really going to cover that very much
 Although what I'm going to talk about is how you make your system open so that
 You can implement inverse and forward kinematics systems
 The reason I'm not going to cover it is it is a complete lecture by itself and it's not really relevant right now
 I won't talk about tools. There's not much I can say about Maya that isn't going to be like really well done elsewhere
 Particularly by the people who make it. So I'm not really going to talk about that really I might
 Take on that is simply use whatever works for you. Now, whatever gives you best results use that there's nothing in particular
 There's no reason that you shouldn't use max or you should use Maya or whatever
 Texture management systems again really doesn't come under an animation system
 That's really DirectX and OpenGL or whatever texture management system. You decide to implement particularly on consoles again
 not really animation and
 Although this is relevant the blending methodologies, even though it is relevant to animation systems
 I'm not really going to cover it too deeply mainly because somebody did it yesterday
 They did a really good one-hour thing on different blending techniques and what you can use them for
 So I'm not going to go into that in too much detail
 So now I've talked about what I'm not talking about. Let's talk about what I am
 This is about animation system approaches
 Good old Frankenstein gotta love him, eh
 Right
 So
 There's three real
 Approaches that you can take
 Going from high level to low level. There's the the open-ended
 The open-ended
 Style which means that you create an animation system that does everything for everybody
 What you try and do is effectively
 Reproduce inside of your engine every capability that say Maya's pipeline or max pipeline can offer you so everything you can do in Maya
 Can be done inside of the animation system itself
 It tends to be really heavy-duty work. There's a lot of code in there
 I mean Maya is a big product and so is max so trying to reproduce everything that they can possibly give you is pretty heavy-duty
 But it tends to be very flexible
 There's almost nothing that you can't do, you know when you say oh I want to do this and that inside of Maya
 Well, yeah follows through it filters through and it works in the game
 Then there's the next step down which is a animation system for multiple general genres, but it's pretty
 Smaller scale you say I'm going to take a subset of what Maya can do for me and just use that
 It says animation for multiple genres that actually tends to be more specific for certain genres
 First-person shooter is going to require a lot more in the way of
 effect
 Modification than say a real-time strategy game will so you have to know what it is that you're writing your animation system for
 Then there's the specific implementation for any given game design
 And the idea is is that you just write that at the lowest possible level you can you tend to do that on consoles?
 a lot
 With entering now a generation of consoles where you do tend to reuse
 Coding and you do tend to reuse your libraries, so you don't tend to do this as much
 But it's still out there
 And it's the fastest way to get it up on screen, and we we all know about that
 We've all had code that we really really regret in the morning haven't we?
 All right
 so I
 personally espouse the modular approach mainly because
 It's nice to be able to like yank bits out and replace them later
 I'm probably not telling you anything you don't already know, but you know I'm gonna go over it
 Anyway, the modular approach is the way to go. I think you can reuse the modules
 And it generally when you do a subset of something that Maya gives you
 It's it's easy to then say well. I need this extra functionality. Let's pull it in
 Okay, so the animation basic setup
 preprocessor or not
 Do you have an extra step between what your animators and modelers produce?
 That you have to pass your your animate models through to make it game friendly, or do you just actually do that all in game?
 people like it traditionally
 They used to have a modeling
 Program that they produced you know a dust based program that you've run on models to make the animations data game friendly
 And they don't anymore
 I think they just import stuff directly inside of doom
 Which is nice because it's really really fast for your animators and your modelers to see
 What they've done and what they've changed they don't have to help go through a whole check-in process
 Run a program that might have bugs in it
 They can just pull it straight into the game
 And it's often quick and easy
 but the the
 Backend of that is simply that you've got a lot of extra processing going on inside of your game
 That you probably don't really need to be doing particularly not when you're shipping
 On consoles you tend to always have a preprocessor step because you have to munch the data
 You know the PlayStation 2 only has 32 megs of memory
 And you can't afford to waste it with 32-bit floats you really need to be crunching that down
 The preprocessor step the most successful preprocessor steps. I've seen are
 Two versions of the game that you're actually running one of which will import data directly
 Like we just talked about that that doom does it will allow your animators to work very quickly
 But then for actual production you will have a preprocessor step that will munch the data down so that you have fast loading times inside
 of the real game itself
 It's a bit extra on the front end to build, but it's certainly worth it
 It really is worth it the ability of your animators to not need intervention and to be able to view stuff directly in-game
 Cannot be underestimated
 Okay
 Another another thing about basic setup is your in-game pre-caching and registration of model data
 The idea is and it's very obvious and basic is you only have one copy of the data in memory at any given time and
 There are many many PC systems that don't do that
 You need to make sure that you have a garbage collection system inside of your animation system once you load a model
 You have to be able to unload it again
 I know this doesn't sound like something you really want to do
 But you do want to do it particularly for specialized circumstances like when you're doing rendered cinematics or whatever it might be
 Because you only want that model in memory at one time, so you need to dump it away again afterwards
 The number of animation systems. I've seen that don't do this
 They just load the model once and it just loads the model again, and then you're good to go
 Again afterwards the number of animation systems. I've seen that don't do this
 They just load the model once and it just sits around taking up memory is outrageous
 So you need to make sure that you have a garbage collection system that will clean your models out for you
 You can do it in many different ways
 You can look at it put a time stamp on the model and just look at see when the last time it was used
 Dump it out when you you know over after a certain bit of time or whatever. There's many ways of doing it
 Memory storage and compression well that kind of ties in with the pre-processor
 You've got space versus speed. I mean that's always the question isn't it space more space you use you're generally the faster
 It is less space you use the more time you have to spend doing things like
 Transformations back from 16 to floating point in order to avoid errors that kind of thing
 You have to make those decisions up front because trying to implement them after your animation system is constructed can be very very scary
 compression is really important, but
 One of the things that I've noticed is that I mean let's say for instance you go with a matrix based which we'll talk
 About in a minute a matrix based animation system if you
 Try and reduce out the floating point accuracy
 You'll notice that so all of a sudden you have a much a large degree of jitter on your matrices because your floating point isn't
 Accurate enough anymore you need to know that up front
 It's not something you really want to be doing later on at the end of the project
 Because all of a sudden bad things will happen, and you don't know what the hell to do about it
 So get that done up front
 file formats
 So you need to separate out at least my experience you need to separate out your mesh and your bone information again
 No brainer, but a lot of people don't
 The idea is that if you separate out your mesh and your bone information you only load the mesh once you can have
 specialized sets of animations
 For each given mesh and then unload those easily whilst retaining your mesh in memory the good example of that would be a cutscene
 When you have a cinematic you've usually got a lot of animations that are specific just to that sequence
 And it's nice that you don't have to unload the mesh as well when you dump out all of your animation data
 Also, you can possibly reuse the same animation data the same skeletal animation data on different meshes
 you
 That's a sort of a dubious area
 Like all two will allow you to do that, but it's not
 It's hard to explain, but you have it's all about the mesh itself if you have a mesh
 That's like got much wider shoulders
 And you try and use the same skeletal on someone that's the skeletal information on someone that's got narrower shoulders
 Then you tend to start getting arms going through the mesh itself because the mesh is out here yet the skeletons still in here
 By and large in my experience you can reuse
 Animation data on a separate mesh that has about a 10 to 15 degrees plus or minus of sizes
 Between them yeah, so you can have one that's got about 15% larger shoulders
 You can get away with it you get much more than that 20% 25%
 And you will start to see a lot of artifacting where polygons move through other polygons
 It's really one of those things where you have to suck it and see just see what works out and what doesn't
 Okay
 Basic setup you have to decide if your animation system is going to be used in a network environment or not that does impact
 How you build it?
 The reason for that is simply that
 You have to decide who needs to know what's going on is it the server that needs to know what's going on does the server?
 Need to know exactly what all the overrides are on all of the bones for collision detection
 That's a must if you're going to do collision detection on your server
 then you have your server has to know what the skeleton what the state of the skeleton is so it can actually transform the
 model on the on the server and
 Have all the vertices in there are correct places to do rape
 What's the word rage tracing through it, so you have to know that upfront
 Quick and dirty implementations of animation systems usually don't take that into account
 They tend to be let's just get it rendering on the bottom end and that's a bit of a problem when you come to do
 Your your clever overrides and and program and control joints and all the rest of it at the other end
 System architecture, how do you build this?
 Well you have there's some questions you have to ask yourself at the time when you do this you have to ask yourself who owns the data
 Where does it reside and who needs to access it what I'm talking about there is I'm talking about the root level information the information for the mesh the information for the skeleton on the rest of it
 Where does this sit do you have a registration system that loads all this stuff in for you which you should do and you should do it
 There should be a registration system that knows where this information is and how to swap it in and out when it says who owns the data it's kind of like you have a specialized system that will handle this and obviously it's no brainer you should do
 Who uses it
 There's two parts to the data
 Really there's the part that static which is the original mesh information usually and I'll make a quantifier on that and then there's the animation data itself the animation data doesn't usually change it's static you load it in once and you don't do anything to it
 But then there's also information that regarding specific bones specific bones and what's running on those specific bones when I want to do
 Hierarchical skeletal animation and I want to override this arm so that I can scratch my head whilst the rest of my body is still doing other things I have to have a system that will tell this bone you need to be doing something different you need to be running a different animation from this point down
 And that's what I'm talking about here is the information that is that all the structure that points at okay this bones doing this this bones doing that and that's that information is going to be the basis for how we're going to do this
 I have to have a system that will tell this bone you need to be doing something different you need to be running a different animation from this point down and that's what I'm talking about here is the information that is that all the structure that points at okay this bones doing this this bones doing that and that's that information is going to be the basis for how we're going to do this
 And that's what I'm talking about here is the information that is that all the structure that points at okay this bones doing this this bones doing that and that's that information is going to be the basis for how we're going to do this
 And that's what I'm talking about here is the information that is that all the structure that points at okay this bones doing this this bones doing that and that's that information is going to be the basis for how we're going to do this
 To use STL or not put this in because I put STL inside of Google too and it was the biggest mistake I ever made it was really stupid.
 STL is really good in terms of registration systems but you shouldn't be using it frame to frame because it does uncontrollable things or unpredictable things with your memory allocation obviously you wouldn't be doing that on a console anyway but in the PC it's very easy and seductive to get sucked into it and it's really good.
 And when you have variable numbers of bones being affected per skeletal per model it's really nice to have this system that just does it all for you but unfortunately it can get very unpredictable.
 At one point we ended up using something like 64 megabytes of STL memory on inside of a soldier of fortune because we just didn't predict what was going on.
 I'm an idiot what can I say when you link your information backwards and forwards when you link okay this mesh is using this animation or whatever.
 You should never use pointers always use indexes because that means you can when you bring stuff back in again when you load it back in again enough to worry about pointers indexes are always the way to go.
 Obviously I guess.
 The links to the rendering information should be contained within the model they shouldn't sorry the particular instance of the entity of the model you don't want to point meshes animations at the static level of when you load this stuff in you want to be doing that.
 At a model at the entity level and the reason for that is so that you can swap meshes really really quickly.
 I want a guy that does you know this guy's getting cut up or has been shot or something like that and you want to swap out the model really quickly.
 It's nice to be able to just say well no don't point at this mesh point of that mesh so it shouldn't be contained within the static side your registration system.
 They should all be separate discrete systems that don't link together.
 I ran into all sorts of problems because I didn't do it that way originally and I had to write a whole bunch of override functionality all ignore what's going on in there do it over here instead and it was just stupid I should have done it the other way in the first place.
 Temporary memory pools.
 Quite often you're going to want to keep results of transforms will model around from one frame to another.
 Things like ray tracing collision detection is one case in point you only want to transform the model once you want to transform the skeletal skeleton once and all of the mesh once and this is assuming of course you're doing it in software and asking the hardware to do it.
 I always do it in software because then I know what's going on.
 When you transform the model.
 You do need to put a timestamp on it.
 So let's say I transform my model and I'm doing this here. I am standing like this.
 I do I then decide I'm going to do a ray trace on this so I ray trace through the vertex is in the mesh that I've just transformed and I find I've hit the guy.
 OK so now I'm telling him OK as a result of the fact that I've hit you. I want you to change your animation now.
 So I need to invalidate the timestamp on the model so that it gets recalculated again.
 Now that I've decided that I'm doing a different frame of animation.
 This is all within one frame you know I should have drawn this up and done this as a as a as a slide but I didn't think of it.
 It's it's all in one frame and the point is that you only want to transform the guy once unless you change something and you can change something as a result of all sorts of different things that happen inside of that frame.
 I may decide to put a gun away or bring out a new one or something like that.
 And the idea is that you need to timestamp your transform.
 Transform the model into temporary storage keep the temporary storage around for the entire duration of the frame.
 Then invalidate the temporary storage on the next frame so it's all fresh to use again.
 But inside of that one frame you may invalidate that particular model anyway.
 I'm not seeing anybody nodding here.
 So the idea is basically you need a temporary pool of memory inside of your system architecture that will basically take the results of any transforms you may do for that frame.
 But you have to have a capability to say this is now out of date I need to do it again.
 OK.
 All right the first thing skeletal hierarchy and bone manipulation.
 This is at a.
 A transform level of how you're handling your models don't muck about storing matrices.
 In goal two I made a mistake of using matrices as my root level transformation for all of the bones in the in the skeleton.
 All of the information was stored as matrices as three by four matrices and it was a mistake.
 Part of the problem that I made was that we were doing linear interpolation of a matrix from one frame to another.
 And that's really stupid because linear interpolation of a matrix will actually give you flat matrices if you if you were moving from 180 degrees to 180 degrees the other way.
 For instance I'm standing like this and all of a sudden I'm going to an animation of a guy getting hit and his arms are behind him.
 That's almost 180 degree rotation you're looking at on one joint right here the arm going all the way back.
 When you do a linear interpolation of a matrix you end up with a bunch of zeros all the way through the matrix which effectively flattens the joint and completely which is really stupid.
 And we saw that an awful lot and you can still see it inside of Jedi Knight 2 in certain circumstances when guys are spinning in the air they will flatten because I use matrices.
 It was a mistake but I was building on top of a half finished animation system that was inside of Quake 3 at the time which is why I did it.
 You definitely want to go with quaternions and the reason for that is simply space.
 They're a lot smaller and secondly they do rotational interpolation in a much nicer fashion.
 When you're actually building your individual matrices for your individual bones one of the things you might want to bear in mind is what information do you really need.
 Do you need an XYZ offset or can you just get away with rotation information.
 You need an XYZ offset if you want to do things like stretching the bone at all.
 Which means that I can make this bone longer because I can make its relative distance from this bone longer so I can stretch the arm out or make it shorter.
 It depends on what your game is whether you need that functionality or not.
 If you don't need the functionality don't store it. Save space.
 Scale is another one. Do you really need to save scale on each bone.
 If you want to get thicker or thinner on the fly it's really not something that's necessary.
 So you can save a lot of space per bones by just storing the quaternion and not going any further.
 Run time based and not frame based.
 The animation systems that I build are always time based.
 There's not really a concept of frame per se. There's a concept of time.
 It starts at this time on the system clock and ends at this time.
 The beauty of using a time based system is simply that you can affect the time of the game.
 Whatever your game is running at you can say I want it to run at timescale 4 or timescale 0.5.
 The animation system will totally cope with it and be really slow.
 We used that a lot for debugging inside of the Quake stuff that we did.
 You want to get away from the concept of frames per se.
 You can do things like the Matrix. I think Jedi Knight did that.
 They had this camera thing where when you cut someone's head off the camera comes out and rotates around and everything slows down.
 It's really the way to go.
 The frame count plus one problem.
 Let's say your animations are given to you by your animator.
 He says this is 10 frames or whatever.
 There's actually 11 frames when you get down to actually animating it.
 There's a start frame animation, the next one, the next one, the next one.
 At the end there's another one that happens when you blend into the next animation that's going along.
 You end up with an issue of there's an extra frame.
 You can end up with all sorts of weird things going on if you don't realise that that's coming.
 There is an extra frame that you virtually add at the end of every animation.
 It can be really messy when you're writing code and you don't realise that's what's going on.
 Somebody says to you this is one frame or whatever and it isn't one frame, it's actually two and it gets a bit messy.
 There's two different types of blending you can do, I call it.
 There's override blending and then there's transitional blending.
 Transitional blending is when you blend from one animation to another.
 You say okay, I'm at the end of this animation and I'm going to move into the next animation.
 I want over this period of time to go from this frame to this frame.
 There's even two degrees of that too.
 There's whole body blending which is where I'm running two animations and I'm going somewhere between the two.
 A good case in point would be let's say for instance you're playing a basketball game.
 What you do is you create two animations, one with the guy with the bat up high and one with an animation of the guy with the bat down low.
 What I'm going to do is I'm going to blend between those two animations to raise the bat to exactly where I want it to be.
 So that I can actually always hit the ball directly rather than trying to create 16 animations that are all between the two.
 I just blend between them and that's whole override blending.
 Then there's smaller override blending.
 That's the idea that I'm running a full body animation that allows me to do an idle for instance standing like this.
 But then I run a partial animation just on this bit to scratch my head.
 That's partial blending.
 The idea is that this is an override animation that 100% takes over what the arm is doing and decides it's going to do something else.
 The other ones are actually two animations munged together.
 I'm not going to go into too much detail.
 There are two different approaches you can take.
 One is I finish this animation, freeze on this frame.
 Don't start the next animation until you've blended across to the first frame of the next animation.
 That's one way of doing it.
 But then you're introducing a virtual frame between the two and the guy is not actually doing anything.
 You can end up with some strange gaps that happen.
 All of a sudden your animations aren't seamless anymore because you've got this one extra frame.
 Then you've got, okay, I'm almost finished with this animation.
 I know I'm going to be finished on the next frame but I haven't quite finished yet so now I'll start blending.
 On the last frame of whatever it is I'm doing I'm going to start blending into the next one.
 Then you've got complete blending between the two where you have both of them running at the same time.
 You say, okay, a frame before or an amount of time before this animation is finished I'm going to start blending into the next animation.
 Those are the three different ways of doing it.
 I tend to use the actual overlap of animations specifically so that one animation hasn't finished when the next one has begun.
 You end up with more seamless stuff there.
 Another benefit as well that you want to provide as a programmer is the ability to modify
 how long one animation is going to take to blend into another.
 Generally a good animation blend time is about 250 milliseconds.
 Almost everybody I know that I've talked to about animation systems tends to use that sort of speed of time,
 the duration of blend from one to another.
 Give that to whoever's coding your animations.
 It's really, really helpful because there's going to be one or two times where you don't want to blend at all because animations are made to be seamless.
 One animation to the next is made to be seamless or you may want a longer animation blend.
 The animation time we had in Ghoul 2 and Soldier of Fortune,
 you can see it sometimes where an animation will end up really nicely like this and then they'll go like this really quickly
 because the animation time wasn't modified.
 That's something we should have done.
 How many blends on one bone at once? If you're doing complete overrides, running two animations at once or whatever,
 you don't want to go much more than about two or three animations because you end up with very unpredictable results.
 If you have more than two running, you now have three different effectors all running on the same bone
 and knowing where it's supposed to be and where it's not supposed to be can get very difficult.
 In fact, if you're doing partial body overrides as well, you can end up with lots of problems
 because you have like 16 different things running at different heights in the hierarchy.
 Because it's all relative, because each bone is relative to its parent,
 sometimes you can end up with very strange things happening.
 It's because there's an animation override running here.
 There's one running here. There's one running here. There's one running here.
 By the time you get down to this, the gun's not pointing in the direction it needs to be.
 It's pointing over there now because of one modification you made down here.
 It's very easy to lose track of what bone is pointing and all the rest of it when you start overriding them.
 This goes into where the inverse kinematics stuff that I mentioned earlier is,
 is that when you allow programmer-controlled joints on any given bone in the body, which is what we did,
 you have to be very careful about how you write code to use that.
 If you're going to write an inverse kinematics system, it can get expensive,
 but you have to be very careful about it because it's really easy to screw it up,
 not just from an implementation point of view, but also from a usage point of view.
 You can't just lose track of one of the bones and all of a sudden the torso's facing that way.
 We saw some of that as well.
 We just did the difference between splines and overlays. Never mind.
 We're talking about the programmer-controlled joints. We'll talk a little bit more about that, I guess.
 Controlling the orientation of a programmer-controlled joint has implication.
 When you build an initial model, quite often you start off with a control pose,
 which is the default position of where the skeleton is.
 By that, I mean that is when all of the matrices that you generate from inside of the skeleton
 are at the identity matrix, which means they're all like 1, 0, 0, 0, 1, 0, 0, 0, 1.
 That's generally something like this or like this. That's the control pose.
 You need to make sure that you understand the orientation of each of the bones at your control orientation.
 When my matrix is not pointing anywhere, the arm is pointing down,
 because when you come to override this and say, I want this to point forward,
 you have to know where the bone was pointing originally to know what forward actually is.
 Is moving my arm up to point forward, is that the z-axis?
 Is it the x-axis or is it the y-axis?
 The only way to know that is to know what the joint was originally when the model was constructed.
 That's quite a complicated thing to get your head around,
 but if you start doing programmer-controlled joints, you will run into this.
 You have to know which way is forward, which axis is forward,
 because when you generate your matrix that overrides whatever the bone is going to be doing,
 you have to fill in the right relevant details.
 Do I fill in the x, y, z, the vector of forward inside of the y or the x or whatever?
 Just bear in mind that.
 The orientation of the bones in the root pose matters.
 What you're probably going to want to do is, when you build your test model,
 your first test model that you build,
 you're probably going to want to sit down with your animators and hammer out a standard
 and say, all models are going to stand like this to begin with,
 or they're all going to be like this, or however they decide to do it,
 just so that you know when you're writing your code which way is forward.
 We talked about the short-term storage of transformed skeletons
 for later use in lighting and collision detection.
 When you write this information out,
 you're basically going to write your entire skeleton out the first time when you come to transform it.
 The skeleton itself is usually pretty fast to transform.
 Probably the fastest part of any of your calculations is going to be the transformed skeleton.
 It's not going to take long at all.
 Everybody worries about, oh, I need to make this faster or pre-optimize it or the rest of it.
 You don't need to do that.
 It's the bottom part of your code, believe me, and it's very, very fast.
 You can do things like lazy bone evaluation,
 which means I'm only going to rebuild any part of the skeleton that's actually changed from the last frame.
 But given the nature of animations these days, almost every frame in the animation will change.
 So lazy bone doesn't really buy you very much, to be quite honest with you.
 We put it in and then found that it made absolutely zero difference to our execution time,
 so it really was a waste of time.
 The variable incoming animation frame rates.
 When you're building your animations to begin with,
 most of the animation systems that I've come across don't use splines,
 they might use splines in actually building the animations themselves,
 but when they output the animation, it's usually a set frame rate.
 You'll get an animation that's given to you at 20 frames per second or 30 frames per second or 10 frames per second.
 Being able to handle a variable speed animation,
 which means that each animation you run is given to you at a different frame rate,
 is very helpful for numerous reasons.
 One of them is that some animations simply do not require 30 frames per second,
 and if you're giving them at 5 or 10 frames per second instead of 30,
 you've just saved a crap load of space by not having as many frames in memory.
 Certain animations, like for instance the gun that bobs up and down in a view in a first person shooter,
 does not need to have 60 frames per second animation, you just don't.
 30 frames per second animation usually should be reserved for animations that have a lot of dexterity in them.
 When you're seeing a lot of bone motion, that's when you need the high frame rates,
 simply because you can lose those high frame rates in your frame to frame interpolation,
 all the nice, small, subtle movements you lose when you reduce the frame rate out.
 And of course it helps with the memory footprint.
 You could, if you wanted to, write an animation system that worked on keyframing,
 whereby the animators will construct an animation that instead of when it's given to you,
 there's one frame every 10 frames on the screen, there's one frame of animation,
 they give it to you and say, right, well there's a keyframe here and a keyframe here,
 and the distance between the keyframes is variable, and you just interpolate between the two.
 You can do it that way if you want to too.
 I've never actually implemented a system that way, but I know a lot of animators that like to work that way.
 It's up to you really, I mean I tend to go with a variable frame rate to begin with,
 because it's just easier to get in your mind the concepts in your mind.
 Debugging animations that have keyframes at odd places can be a real pain in the ass.
 Okay, mesh surface and hierarchies.
 The animation systems that I've constructed actually have a hierarchy for the mesh as well.
 In the same way that your skeleton has a hierarchy, there's the root bone in here,
 and the hierarchy goes down, the meshes do the same thing.
 And the reason for that is the ability to reset the root surface or to deactivate parts of the model.
 The idea is that I can then, if the mesh is a hierarchy, this is a subset of this, is a subset of this,
 I can turn off this mesh right here and automatically these meshes go away as well.
 I don't have to turn off each individual mesh that's going on.
 I can just turn one off and the whole thing goes away.
 And it's beautiful if you want to blow an arm off, because then boom, blow this arm off,
 turn off these meshes and it's gone.
 And the other thing about it is nice that you can hide extra meshes inside of the model that way as well.
 So for instance, when I have an arm here, there's also a mesh that's hidden inside,
 there's a jaggedy, ragged edge inside, so when I blow his arm off,
 I turn off these meshes and turn on another mesh behind it, which is the raggedy bottom bit.
 The ability to reset the root surface is really nice.
 It means that effectively I can put two models on the screen.
 When I blow this arm off, I turn off these meshes here on the main model of the guy.
 But then on the floor, I want to have an arm.
 So what I do is I generate another model, I just duplicate the model of the guy,
 but I reset the root surface at the arm.
 And the idea is then that only the arm downwards is drawn,
 because at this point I'm not starting at the bottom of my mesh hierarchy to draw,
 I start halfway down.
 That gives you a lot of power to be able to just draw specific parts of a model that you want to do.
 When you want to leave bits lying around on the floor, that's quite nice.
 Level of detail.
 Because you've divorced your mesh from your skeleton,
 you can actually effectively swap out models on the fly.
 That's how the Quake stuff does it.
 They don't have any level of detail going on,
 they just swap models at a specific distance and voila, it works.
 By separating out your mesh, it gives you that capability.
 You can even get really sophisticated if you want to
 and start using some of that Intel stuff that does continuous level of detail.
 Although, excuse me, with this day and age, you don't tend to use that very much.
 One of the things that you have to worry about is hardware transform and lighting.
 If you use hardware, you don't get the results.
 If you want to do per-polygon collision detection, you need those results,
 so you need to do it yourself.
 Callbacks and events.
 Inside of an animation, you probably, at some point,
 want to have something triggered from the animation itself.
 You want to say, on frame 20 or this particular time into the animation,
 fire off something that happens.
 You want that to be animator controlled.
 What animators need to put into the animation itself,
 specifically where they want this event to happen and what this event needs to be.
 It's just a given thing. You really need it. You do need it.
 Particularly for things like tying footsteps to footfalls.
 As the foot hits the ground, boom, you hear that. You hear the sound.
 It's really nice. It's the way to go.
 I just can't tell you how important it is.
 That should be one of the first things that you do when you build an animation system
 is give yourself the callbacks or an event tree.
 Work out a way with your animators that they can pass you the information
 inside of the file that they generate.
 Usually it's just like a number.
 They'll say, at 250 milliseconds in, event number 12 gets called.
 Then you on the back end handle, oh, event 12 got called.
 You look at your, what time is it now? What time did the animation start?
 Look at the event list. Oh, I need to fire one off.
 It's not hard to do, but it's really important.
 One of the things that you shouldn't be doing is inside of these callbacks and events
 is resetting your clock, the game clock.
 You may want to slow down an animation or speed it up or something,
 but don't do it inside of a callback or an event
 because you will screw up everything else that's going on
 inside the animation system at that current point.
 God, it's early in the morning, isn't it?
 Way too early in the morning to be doing things like this.
 Adding motion to animations.
 Generally, if you're doing things like motion-captured animations,
 you end up with the motion built into the animation itself,
 and you have to actually go back and remove that motion from the animation
 because you, as a programmer, need to control where the entity is in the world.
 As an example of this, I have an entity that has a model attached to it, and here it is.
 The entity stays here. I have an animation that's a walk animation.
 The walk animation will make me walk out,
 and I can walk right off the edge of this podium and just stand in the air
 because the game thinks the model is standing right here, not over there.
 You don't know where the model actually is in real space
 because you think the model's over here. That's where you're telling its origin is.
 So what you need to do is strip out the motion from the animation itself.
 Now, because motion capture is not standard, it's not nice,
 every frame is slightly different of offsets, you end up with a bit of a problem
 because you can't just say, right, have the guy stand still and do all his motion
 and I will control his forward speed because at that point, all of a sudden,
 he starts jittering around because the animation isn't lining up.
 The original motion capture animation wasn't smooth in terms of how it walks.
 So the solution, basically, is to take the original animation with the motion still in it.
 Every frame, you reset the guy back to...
 Take the start position of where the guy is and the end position of where the guy is
 and that gives you your total distance traveled.
 You then take that, divide it by the number of frames that you have.
 So if you have a 10-frame animation, you divide that distance by 10
 and subtract that value from wherever the guy is in the world per frame in your preprocessor.
 Does that make sense?
 Basically, you're subtracting a delta every frame.
 Effectively, what happens then is the guy ends up standing here in one place.
 If you run the animation without moving him, he will be in one place,
 but he'll move backwards and forwards slightly on every frame.
 What you then do inside of the game engine as you're moving the guy forward
 is every frame you just add whatever delta it was that you subtracted
 from the original animation when you were preprocessing it.
 The guy will then appear to walk in the world.
 He's actually walking in the world and he'll walk completely smoothly
 and he'll do exactly what he did inside the original animation.
 But you have managed to retain control now of exactly where the guy is in the world totally.
 The one problem that you have there is arcing.
 This is really linear. It's not really very good for arcing stuff.
 So if you have a guy that jumps up in the air, traditionally guys arc in the air.
 They do a big arc.
 With this one, you'll end up with a linear interpolation that goes down like that
 and you don't have offset.
 Each frame of the animation will be offset slightly higher and slightly lower.
 One of the other problems, of course, is that if you do one complete jump as an animation,
 because the start position Y and the end position Y is both zero,
 you don't actually strip out the height of it at all.
 So what you have to do is cut the animation in half.
 That's the way to do it.
 So all of your jump animation should actually be in half.
 And that's how you get away with doing this whole motion thing.
 I'm running out of time here, so I'm going to move a bit fast.
 Bolting, attachment tags, whatever you want to call it, blah, blah, blah.
 The idea is that it enables you to attach geometry to an existing model.
 I want to put a gun in my hand.
 So I have a bolt inside of my hand and I want to put the gun in it.
 And the idea simply is that you get the matrix for wherever that hand happens to be.
 You transform the skeleton, get wherever that hand happens to be
 and use that matrix as your root transformation for your next model.
 So automatically it's then going to be offset into the right place in his hand.
 The question is, how do you get where that bone is or where that position is in the world?
 There's different ways of doing that.
 You can make it a bone inside of the skeleton itself if you want to.
 That's how they did it originally in Soldier of Fortune.
 The problem with that approach is simply that that bone has to be animated.
 If you construct 1,600 animations and then all of a sudden you realise
 you need another attachment point in the hip somewhere,
 well that means you have to go back and reanimate all 1,600 frames
 in order to have that bone move with the body appropriately, which can get a bit scary.
 So I'm more of an advocate of doing things with mesh tags.
 The idea is simply that you create on the initial model a right-angled triangle that sits,
 that is never displayed, it's a particular type of surface, it's never displayed,
 but it's a right-angled triangle that sits where you want the bolt to be.
 You transform the skeleton and then you transform just that triangle
 because the triangle is weighted exactly the same way as all the triangles would be
 inside of the mesh inside of a hand.
 It's weighted to the same bones, which means that when you transform it,
 it will be in the appropriate place.
 All of a sudden you get back a vertex and an orientation.
 It gives you exactly the same results as a skeletal attachment would,
 but it's a lot, lot cheaper and you can add it right at the end of your modelling and animation
 and it's just great because you don't have to reanimate or re-export anything.
 And it also gives you the ability, if you build a system like that,
 it gives you procedural attachment points.
 And the idea is that that triangle I just described, you can build those on the fly.
 You can do like ray tracing, collision detection, oh I got hit there.
 You know exactly where and what polygon you hit.
 You can generate one of these right-angled triangles
 and therefore give yourself a new bolt point.
 So you can bolt on, you know, like gore or whatever you might want to do.
 So you can do that procedurally.
 It's very, very powerful.
 That's how they did most of the gore stuff inside of Ghoul 2.
 It's done that way.
 We're going to run into the polygon ray tracing collision detection.
 I'm going to do ray tracing collision.
 I'm not going to worry and talk too much about world collisions with a high polygon model
 simply because you just don't want to be doing it.
 It's too expensive, particularly with the polygon counts we see these days
 of 3,000 or 4,000 polygons.
 You don't even want to think about or contemplate colliding all those with the world.
 It's just very scary.
 So the first thing you need to do is obviously have a bounding box early discard.
 You should have a bounding box around the guy
 because that's probably what you're using with collision with the world anyway.
 And that's what you use with collision with people.
 So you take your ray trace.
 Does my ray go through this box? Yes or no?
 Yes it does.
 Okay, well then I'll consider the rest of it.
 For the bones themselves,
 there are all sorts of different ideas for early discard.
 One of the things you can do is for each bone you draw a sphere around it
 and you do the ray trace through the sphere.
 Did I collide with the sphere? Yes or no?
 The trouble with that is sometimes if you have long extended bones,
 like antenna for instance on an alien or something,
 your spheres you start generating are bloody huge.
 And the other problem of course is that they're at the end of the bone
 when really they need to be in the middle.
 And a lot of systems will actually say,
 okay, well I'm going to generate a sphere.
 I'll take this bone and this bone, interpolate halfway between them
 and then draw a circle there.
 And that works too.
 But also you have to be very careful about where your spheres go
 because it's quite easy to have a sphere that's just slightly short
 and the sphere here is just slightly short
 and you end up with a bit here that never gets hit.
 So you need to be careful with that.
 You can do ellipsoid as well.
 That's fairly cheap as well.
 And then you do a surface bounding box ray trace.
 Now this is even cooler actually.
 This is something we did for Google too.
 When you generate, when you do your transform
 of each individual surface of your model,
 as you're doing the transform, put in a small bounds checker
 that determines the furthest vertex in that mesh.
 What you're doing there is effectively, per frame,
 is generating a bounding box for just the surface that you're rendering.
 So if I'm just rendering this part,
 it's effectively going to build me a bounding box that's just for this.
 And that's a really nice, quick, easy discard.
 That's really powerful and very, very fast
 and it's almost no expense,
 although there is a decision maker for every vertex that you do a transform on
 and that can be expensive.
 When you actually come to do your ray trace,
 effectively, when you get down to a polygon level,
 you're just basically doing a planar decision.
 Does this plane bisect this plane or not?
 And I'm not going to tell you how to do that
 because there's plenty of examples on the web to do that.
 But one of the things you want to do is,
 again, this is how I did it,
 is I returned, from when I do a ray trace collision detection,
 I do not return immediately on the first hit
 because you may have multiple hits through a model.
 You may have, if I'm standing like this,
 I'm going to have multiple hits for a ray trace.
 I've got the outside of my arm, the inside of my arm,
 then the outside of my torso, and the inside of my torso.
 And if you build your models in a very complicated fashion,
 you can end up with huge numbers of hits as you go through.
 Inside of your ray trace routine,
 one of the things you want to do is keep track of the actual distance
 of where the hit occurred from the origin of the ray trace
 because that enables you to sort the results
 on a distance from where the ray trace hit.
 So what that effectively means is you'll return
 the order of hits from front to back.
 You're getting here, then here, then here, then here.
 Because quite often your mesh order
 won't be the same as the ray trace order.
 So you want to pre-sort your results.
 One of the other things you can do is
 you can also look at the orientation of the polygon you collided with
 which will tell you whether it's an entry or an exit.
 Am I being hit coming in or am I being hit coming out?
 That's something that's very useful
 because that way you can determine, right,
 OK, I'm going to bolt incoming geometry or an explosion out.
 I'm going to attack particles on the back end.
 And if you return information on which polygon got hit,
 which surface it was, and the barycentric coordinates
 of where the polygon was hit,
 barycentric coordinates basically are the offsets
 from the corners of the triangle itself.
 It's saying, OK, I'm 20% in here and 30% in there.
 You can use that information in other ways.
 One of the things you can do for grabbing hit location
 is you end up with a second,
 for every mesh you end up with a second texture for it.
 And the second texture is just paint,
 broad painting colors is all it is.
 And the colors themselves will give you information
 on what it is that you hit.
 So when I say, oh, right, this polygon got hit,
 I know what the barycentric coordinates are for this polygon.
 I can look at the second texture page
 that goes with this polygon
 that's laid out in exactly the same way
 as my rendering texture page.
 And I can say, well, I know where the polygon is.
 I know where the rendering coordinates are
 for this particular bit of visual information
 inside of the texture page.
 I know exactly where within that triangle I hit.
 So I can go and look at the color
 that's inside of that second texture page,
 get information out of it, and say, well, it's green.
 Okay, green means it's flesh.
 Red means it's metal.
 And that way you can get a per-polygon
 or per-pixel accuracy
 of exactly what it was you hit,
 which is really helpful.
 Networking considerations,
 we talked a little bit about that.
 Client v. server.
 If you're doing per-polygon collision detection
 and you're doing ray tracing,
 you need to do that on the server.
 You can't afford to do that on the client
 because the client can be wrong.
 If the client's animation data is slightly out of phase,
 all of a sudden you miss somebody
 that you should have hit.
 Networking has to handle overrides on bones.
 You have to be able to pass down
 what the server thinks the model is doing,
 which means on a per-bone basis,
 the server has to pass down to the client,
 this bone is being overridden,
 this bone is being overridden,
 so that the client accurately represents
 what the server thinks it's doing.
 And this also means that the server
 actually has to load the model information
 and transform the mesh.
 Up until now,
 most of those client server implementations,
 the server hasn't needed to know
 about any of what the model is doing
 because it doesn't care.
 When you're doing bounding box collision detection,
 who gives a rat ass
 what the animation that's running is?
 But now that you're doing
 per-polygon collision detection,
 the server has to know about this information.
 Remember I talked earlier on
 about having one pool of information
 that you load models from.
 One of the problems we ran into
 was we had client running on a server
 on the same machine.
 It loaded up two sets of models.
 It loaded one up for the client
 and one up for the server.
 Well, that's pretty stupid.
 Level of detail in networking is quite nice.
 If a guy is really, really far in the distance,
 it really doesn't matter
 what animation he's running
 because you're not going to be able to see it anyway.
 So don't bother sending bone override information
 from more than a certain distance away.
 I'm hurrying up now
 because we're almost out of time.
 Questions and beer.
 Yeah, it's nine o'clock in the morning.
 I didn't realize I was going to be
 at nine o'clock in the morning.
 Anybody got anything they want to ask?
 Oh, come on.
 Yeah.
 You talked about not supporting offsets.
 Yeah.
 Does that mean you can't do weighted skinning?
 No, no, no.
 The question was,
 you talked about not supporting offsets
 within the bone information
 and he's saying you can't do weighted skinning.
 No, no, the offsets inside the skeleton,
 not inside the mesh.
 You store the percentages
 that you want to do your weighting to
 inside of the mesh,
 not inside of the skeleton.
 By and large,
 you don't generally need
 more than about four to six weights.
 A lot of PlayStation 2 implementations
 don't handle more than four offsets
 because of the way the vertex units are built.
 So generally, we never found more than,
 you can get away with about four weights per vertex.
 You don't really need more than that.
 Yes, in the back.
 How do you handle a champion
 who's built a multi-offset?
 For example, if you're on a console
 that has a split switch
 or anything,
 you have to attach it to the...
 Yeah.
 How do you handle that
 in the,
 if I do a upper channel
 and go back to the start,
 is that now a large problem
 or is there a larger problem
 or a smaller problem
 and I have to go back to the start?
 Or is it now whether it's really
 you have to match up everything
 as much as you possibly can
 like a full material
 Right.
 The question was about
 about how,
 supporting hardware TNL
 for smaller models
 like when you just want to blow an arm off
 and you only have something
 that's 20 polygons or 40 polygons
 or something like that.
 Traditionally,
 in the systems we've implemented,
 we haven't used hardware acceleration
 simply because we need the results
 of everything that comes through.
 I'm going to say exactly
 that the software,
 the transformation that you've got
 in the software
 is that you deal with those events.
 There's no hardware TNL
 or Turing,
 that you're going to slap it down.
 It's not going to, like,
 you know,
 mess things up.
 Yeah.
 It's not going to
 I don't know,
 but there's a
 I feel like there's usually
 a little bit of clock
 in the software
 that you're getting results
 coming out through the software.
 Yeah.
 That's what I'm wondering about
 because, like,
 where do you have polygons
 and where do you get the software
 from?
 Let's talk about that,
 let's take that offline in a bit,
 OK,
 because that's quite an involved question.
 Yeah.
 Hi, Chris.
 So you were talking about
 mentioning tool maps
 and animations.
 Yes.
 Let's say you're playing games
 and you're walking around
 with a transition animation.
 Yeah.
 And you were talking about
 footsteps, for example.
 Yeah.
 Do you want to,
 how do you filter
 your events?
 Um.
 Do you have a text file
 that you're running
 in an instance
 with two animations
 that have events?
 What do you do about
 those events
 that you've got on or off?
 Right.
 What we actually do
 with that,
 the question, basically,
 is about events
 and saying, OK,
 you've got two animations
 that are running,
 you're blending between
 an event called from
 the new animation
 and an event called
 from the old animation.
 And the example used
 was walking.
 There are two stages
 to that question.
 The first is,
 we have a hierarchy
 of events.
 We have a current animation
 running and a blend
 to animation that's running.
 The current one
 is always the one,
 because until the current
 one is ended,
 the current one
 takes cardinal.
 And what we do
 is inside of the event
 itself,
 the event says,
 am I a cardinal animation
 or am I the blend animation?
 And it will do
 its own appropriate
 determination.
 But the event itself
 will handle,
 do I need to be called
 or am I being blended from?
 Because if I am
 being blended from,
 I don't need to be called.
 The other question
 is about blending
 from a run to a walk,
 which is one of the
 biggest problems
 that everybody has.
 The solution to that
 is to make sure,
 and I know this is
 very hard to do
 from an animating
 point of view,
 is to have the same,
 the walk and the run cycle
 have the same number
 of frames
 and the feet
 are in the same place
 at the same time,
 approximately,
 inside of an animation.
 So,
 the animation itself
 will start
 with the right foot
 forward in your walk
 and your right foot
 hits the ground
 at approximately
 the same time
 as the right foot
 would hit the ground
 when you're doing a run.
 It's very hard
 to do convincingly
 by your animators
 but it is the best solution
 and that way
 you can actually
 just blend right across
 using a software blend
 rather than using
 a transition.
 Yeah.
 You were talking about
 doing linear interpolation
 and the actual
 movement of the character.
 Yeah.
 You know,
 it starts
 followed by a number
 of frames.
 Yeah.
 Do you want to do
 like skating?
 No.
 And then stairs
 where you have
 monolinear walk and run.
 Ah,
 okay,
 that's an interesting thing.
 The question is
 how do you avoid skating
 and how do you,
 with the linear interpolation,
 and how do you avoid,
 how do you deal with stairs?
 The two,
 the avoiding skating,
 if you do it
 by taking the original
 animation speed,
 the original animation distance,
 the travelling inside
 of the original animation
 and divide it up,
 you actually do avoid skating
 and the beauty of it is
 is that also
 if you affect the speed
 of the guy moving forward,
 if you want to move him slower,
 you can actually then just,
 whatever you multiply
 the speed you're moving
 forward by,
 you multiply inversely
 by the speed
 of the animation,
 his feet,
 he will actually
 absolutely be,
 his feet will hit the ground
 exactly the right time.
 So all of a sudden
 you're saying
 I'm slowing down
 the animation
 and I'm slowing down
 the distance at which
 it travels and then
 it works.
 We use it a lot
 actually in the
 pathfinding
 in the
 Next Generational
 Sims product
 that we're doing
 because we have a lot
 of problems with
 going round corners
 and you know,
 okay I want to go
 from point A to point B
 but you have to,
 you speed him up
 from point A
 and then slow him down
 before he hits point B
 and we end up using
 that an awful lot
 and it works just fine.
 The whole approach
 handles,
 that's the whole point
 of the approach
 is it handles
 non-linear speed.
 That's the point
 because every frame
 is different.
 If you ran the animation
 just standing still
 you'd see the guy
 do this
 backwards and forwards
 because his animation
 per frame
 is offset just slightly
 and the animation
 is,
 the offset
 is built into
 the animation
 per frame.
 I'll come talk to you
 about it afterwards
 and I'll show you
 exactly what I mean.
 Going upstairs,
 split frame,
 go upstairs,
 split the animation
 into every step.
 That's the,
 a lot of people
 tend to set up
 animations
 with the complete set
 of all the feet moving
 all the way through
 a complete stare.
 Don't.
 Split it into about
 three positions
 and you'll be fine.
 We ran into
 exactly the same problem.
 Yeah.
 For full view detection
 have you tried
 your screen
 for,
 to get to
 and get it
 out of frame
 before?
 That,
 we,
 yeah we did.
 What we started to do
 as well was we
 started to visually,
 visually render
 the spheres themselves
 so that we could see
 what was going on.
 The spheres started getting,
 dependent upon not knowing
 where the animation is
 and whatever your
 overrides might be,
 the spheres started getting
 so big
 that they encompassed
 almost half of the model
 to begin with.
 So we felt,
 sort of thought,
 well,
 at that point,
 you know,
 the ray trace is succeeding
 so much,
 why bother?
 You know what I'm saying?
 The spheres are so big
 that the ray trace
 happens to hit a lot.
 No?
 Okay.
 Alright.
 Please fill out your forms
 and stuff.
 Cool.
 Cheers.
